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METHOD AND APPARATUS FOR 
DETERMINING COMMUNICATION PATHS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to communication path determina- 
tion techniques. More particularly, this invention relates to 
methods for determining communication paths between 
devices where multiple coupling, mechanisms are impli- 
cated. 

2. The Prior Art 

The IEEE 1394 multimedia bus standard is to be the 
"convergence bus" bringing together the worlds of the PC 
and digital consumer electronics. It is readily becoming the 
digital interface of choice for consumer digital audio/video 
applications, providing a simple, low-cost and seamless 
plug-and-play interconnect for clusters of digital A/V 
devices, and it is being adopted for PCs and peripherals. 

The original specification for 1394, called IEEE 
1394-1995, supported data transmission speeds of 100 to 
400 Mbits/second. Most consumer electronic devices avail- 
able on the market have supported either 100 or 100/200 
Mbits/second; meaning that plenty of headroom remains in 
the 1394 specification. However, as more devices are added 
to a system, and improvements in the quality of the A/V data 
(i.e., more pixels and more bits per pixel) emerge, a need for 
greater bandwidth and connectivity flexibility has been 
indicated. 

The 1394a specification (pending approval) offers effi- 
ciency improvements, including support for very low power, 
arbitration acceleration, fast reset and suspend/resume fea- 
tures. However, not all devices meet the 1394 specification 
and not all devices communicate by way of the same 
protocols. 

In distributed driver architectures, multiple communica- 
tion paths may sometimes be available for controlling a 
remote device. For example, a 1394 and RS-232 serial 
connection may exist between two nodes implementing a 
distributed driver architecture. In order to determine the best 
connection to use, an application has to be able to determine 
the communication path of each connection. 

Old methods of distributed driver architectures (e.g., the 
Home Audio/Video interoperability, or HAVi, architecture) 
do not provide any means of ascertaining the communica- 
tion path used to access a remote device. Only an ID is given 
for the end device. In the case where two communication 
paths are available, some implementations may provide two 
distinct IDs but no means for determining the communica- 
tion path used for each ID. 

BRIEF DESCRIPTION OF THE INVENTION 

This invention provides a method for determining the 
communication paths used to access remote devices. In the 
case of two nodes connected by two paths and an ID for each 
path for a remote device, this invention provides a means of 
ascertaining the communication path associated with each 
ID. 

In one implementation of this invention, each driver in the 
distributed system provides a device name stack service 
which returns a string containing an ordered list of the names 
of the drivers in the driver stack. For most drivers in a driver 
stack, this service calls the device name stack service for the 
next driver down the stack and then adds the name of the 
current driver. This recursive procedure will produce the 
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ordered list of the names of the drivers in the driver stack 
where the highest layer driver name is first and the lowest 
layer driver name is last. 

In the case of distributed drivers, the device name stack 

5 service starts by performing activities within the capabilites 
of regular local drivers. This first activity produces a list of 
names of drivers down to the lowest driver used for trans- 
mitting messages to the remote node. The resulting string 
only contains local driver names. It does not provide any 

10 information about the remote node. Thus, the second activity 
of the device name stack service sends a message to the 
remote node requesting its device name stack service. The 
receiving driver will have two driver stacks below it, one for 
the messaging stack and the other for the target device driver 
stack. The remote driver's device name stack service then 

15 calls the device name stack service for its messaging stack 
and reverses the order of the list of driver names; thus the 
lowest layer driver name is first and the highest layer, that of 
the remote driver, is last. Then, the remote driver's device 
name stack service calls the device name stack service for its 

20 target device driver stack and appends the result to the 
reversed messaging device name stack and returns it to the 
local node. The local device name stack service appends the 
remote device name stack to the local device name stack 
which results in an ordered list of device driver names 

25 participating in the communication path between the local 
node's application and the remote target device. 

This same method may be used to produce a list of device 
classes, device unique IDs, or any other information desired 
of the communication path. That is, instead of merely 

30 indentifying the drivers, path specific information may be 
obtained instead. For instance, instead of ascertaining that 
the path in question includes a 1394 link, perhaps throughput 
information would be provided. 
This method may also be used in a bridged system where 

3S the remote target device resides on a different bus from the 
local node with an intermediate bridge node. In this manner, 
a path including the bridge may be ascertained as may be 
useful in certain applications. 

4Q The information provided by the device name stack may 
be used by a controlling application to determine the best 
communication path to use when multiple paths are avail- 
able for the same remote target device. Thus, in the case 
where both 1394 and RS-232 communcation paths are 

45 available, the application can determine which device driver 
ID corresponds to the 1394 path and use that one due to it's 
higher performance capabilities. 

Therefore it is an object of the present invention to 
detemine communication "paths is a system of nodes. 

5 q It is another object of the present invention to differentiate 
one of many communication paths amongst a plurality of 
nodes in a system. 

It is yet another object of the present invention to provide 
the communication paths determined in an ordered string 

55 including relevant driver information therein. 

Viewed from a first vantage point a method for building 
a communication path representation is disclosed, compris- 
ing in combinaiton, getting driver information for each 
driver in the path; ordering said driver information sequen- 

60 tially in a list; and presenting said list upon request to 
requesting applicaitons. 

Viewed from a second vantage point a communication 
path determination system is disclosed, comprising in 
combination, a plurality of nodes; one or more communi- 

65 cation paths coupling said plurality of nodes to each other; 
and means for defining said communication paths in ordered 
lists. 
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Viewed from a third vantage point in a memory space, a 
method for determining a communication path is disclosed, 
comprising in combination, starting a local name stack 
service; gathering information about all local drivers on one 
or more communication paths; adding said local driver 
information to one or more ordered lists correlated to each 
communication path; starting a remote node name stack 
service; gathering information about all remote node drivers; 
ordering said remote node driver information in a list; and 
adding, said remote node ordered list to said local node 
ordered list, 

BRIEF DESCRIPTION OF THE DRAWING 
FIGURES 

FIG. 1 is flowchart of a method for building a commu- 
nication path string of the present invention. 

FIG. 2 is a schematic drawing of a first embodiment of the 
present invention. 

FIG. 3 is a schematic drawing of a second embodiment of 
the present invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

Persons of ordinary skill in the art will realize that the 
following description of the present invention is illustrative 
only and not in any way limiting. Other embodiments of the 
invention will readily suggest themselves to such skilled 
persons having the benefit of this disclosure. 

Generally, a recursive method is disclosed for building a 
communication path string, wherein a plurality of devices 
may include a plurality of communication paths between 
each of the plural devices. In particular, where multiple 
nodes are coupled together via multiple communication 
paths, this system provides point to point driver data regard- 
ing available paths. By providing such available path 
information, an application, for example, may then use that 
path information to make a path selection determination. 
Alternatively, the above mentioned application may present 
the path data in a user understandable format to a user so that 
the user may manually select a desired communication path 
via the application. 

Referring now to FIG. 1 a system for building a device 
communication path string 10 is depicted. This system is 
initiated by a call or request for communication path data 
from, for example, an application on a local node to the local 
device name stack service. As indicated in block 12, a device 
name stack service is first initiated at a first local driver 
downstream from the application. The device name stack 
service is a rudimentary service included with each driver 
that performs the function of providing its driver informa- 
tion in response to such a call and passing the request along 
with its added driver information to the next driver down- 
stream. This process is continued until the ultimate or last 
driver provides its information and then the path information 
is returned in the form of a string to the requesting appli- 
cation. 

That is, once the name stack service is initiated, as in 
block 12, the driver first in line provides certain self- 
descriptive information as in block 14. That self-descriptive 
driver information is then added to a (initially blank) 
dynamically constructed communication path string. The 
string will be compiled in such a manner as to provide all 
obtained self-descriptive driver information from each and 
every driver in the path in an end to end, driver by driver, 
list. Once the first driver adds its self-descriptive informa- 



8,750 Bl 

4 

tion to the list, it will then pass the request on to the next 
local driver until all local drivers have similarly added their 
self-descriptive information to the string as in blocks 16 and 
18. 

5 Thereafter, once all local driver information is gathered, 
the local device name stack service sends a request to the 
next remote node. The remote node, then, initiates its device 
name stack service to collect all of its driver information as 
in block 20. A remote node will differ from a local node in 

10 that the remote node will also include the target device 
which is intended to receive messages from the local node 
application. The name stack service on the remote node then 
will have two stack lists to compile. The first is that side in 
closer proximity to the local node, or what is called the 

15 message stack. The second is that which is in close prox- 
imity to the target device, which is called the target device 
driver stack. 

Hence, once initiated as in block 20, the remote node 
device name stack service gathers its message stack drivers 

20 one at a time until all message stack drivers are listed in a 
string as in blocks 22-26. Then, after all of the message 
stack drivers are thusly assembled, the stack order is 
reversed as in block 28. This is done to provide the stack 
order in an ordered path when viewed from the perspective 

25 of the local node. Before reversing the stack, the drivers are 
ordered with a view from the top of the remote node. 

Thereafter, the remote node calls upon the target device 
drivers for their driver information as in block 30. Again, the 

3Q drivers are gathered in order from the top of the node as in 
blocks 32 and 34, which is now in a proper order, at least as 
viewed from the perspective of the local node. Once all of 
the target device drivers are so gathered, that stack list is 
appended to the reversed message stack list as in block 36. 

35 Hence, at this point, at least form the perspective of the local 
node, an ordered list of this remote node's drivers has been 
compiled in a string. 

That string is then sent to the local device name stack 
service as in block 38. The local device name stack service 

40 then appends the remote string list to its previously 
assembled local driver stack list string as in block 40. This 
same process is accomplished for each available communi- 
cation path between the local application and the target 
device. If no more remote nodes exist, this process is 

45 complete and includes an ordered list of all drivers between 
the application and the target as in block 44. If, on the other 
hand, there are additional remote nodes between the appli- 
cation and the target device, then, as block 42 indicates, this 
same process will recurse back to block 20 and gather that 

50 remote node's driver information. 

In use and operation, and referring now to FIG. 2, an 
exemplary embodiment 110 is depicted. This embodiment 
includes a local node 112 (node 1) and a remote node 136 
(node 2). The nodes 112 and 136 are coupled to one another 

55 via both a 1394 connection 132 and an RS-232 connection 
134. Therefore, two available communication paths exist 
between nodes 1 and 2 which may be utilized by an 
application 114 on the local node 112 to serve up messages 
on the target device 148 (an LCD display) on the remote 

60 node 136. Hence, it would be desirable for the application 
114, or a user thereof, to be privy to information regarding 
each of the available communication paths so that one or the 
other or both may be selected for transport of messages from 
the application 114 to the target device 148. 

65 In this example, then, upon the sending of a communi- 
cation path request by application 114, the local device name 
stack service initiates. The local device name stack service 
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preferably resides within an 10 coordinator between appli- The target path is the same as that for the 1394 path above, 

cation 114 and GMZP 118. The local device name stack namely: "/ZPGM/GM65550", When added together they 

service is in operative communication with GMZP 118, a form the remote node driver path: "/Terml6550/ZPDTerm/ 

local graphics client driver. For reference purposes, grafman ZPGM/GM65550". Thereafter, this remote node driver path 

116 is a rudimentary graphics software program which is 5 is sent to the local node 112 where the local device name 

able to convert linedraw messages from application 114 into service receives same and appends it to the local driver path 

appropriate graphics commands that will be understood by forming: "/GMZP/ZPDTerm/Term403/Terml6550/ 

an LCD graphics driver, such as the one located on the ZPDTerm/ZPGM/GM65550". 

remote node 136 as GM65550. Thereafter, the local device name service will report both 
Upon receipt of the path request from application 114, 10 strings back to the requesting application 114. The app hea- 
then, as shown in FIG. 1, the local device name service tion 114 or a user thereof may then ascertain additional path 
begins the dynamic path string building routine. Therefore, information as so provided within the communication path 
as the GMZP driver 118 is first in line from the application strings. 

114, certain GMZP self-descriptive information is added to Referring now to FIG. 3, wherein like components per- 

a string, such as its name: "/GMZP". Of course, other 15 form like functions as compared to the FIG. 2 components, 

information could be included in the string instead, such as, a second exemplary embodiment 200 is depicted. This 

"client„driver", depending on the needs of the system. embodiment includes a local node 212 (node 1), a bridge 

Thereafter, two driver stacks are encountered locally. One node 228 (node 2), and a remote node 248 (node 3). The 

is related to the 1394 stack and one is related to the RS-232 local node 212 is operatively coupled to the remote node 248 

stack. Each will be addressed individually, though the paths 20 by means of a 1394 cable 226 and an RS232 cable 246 by 

are compiled sequentially. Referring then to the 1394 local way of the bridge node 228. As will be seen, the same 

stack, the next driver encountered is ZPDTNF 120 (a 1394 general methodology will apply to this embodiment as was 

transport driver). ZPDTNF 120 is thus added to the path applied to the first embodiment. 

string resulting in: "/GMZP/ZPDTNF". Likewise, the 1394 In this example then, upon the sending of a communica- 

link driver, Link8412 122, for the physical link MD 8412 25 tion path request by application 214 to the local device name 

124 is added next to the string, resulting in: "/GMZP/ stack services at GMZP 218, "/GMZP" is added to the local 

ZPDTNF/Link8412". Hence, the local 1394 stack has been path string. Thereafter, the remainder of the local path is 

built, moving the process to block 20 of FIG. 1. constructed by polling the ZPDTNF driver 220 and the 

Hence, the local device name service stack next sends a link84 13 driver 222. The result is a local path string depicted 

request to the remote node 136 for its path information. as "/GMZP/ZPDTNF/Link8413". 

Similarly, on the RS-232 branch, the following is built Thereafter, the GMZP device name stack service sends a 

locally, prior to sending a request to the remote node 136: message to the bridge node 228 ZPGM 236 (the bridge 

"/GMZP/ZPDTermyTerm403". Where ZPDTerm 126 is a server driver) to construct its path. ZPGM's path consists of 

terminal driver for RS-232 bus communication and Term403 35 ZPGM and the drivers between ZPGM and node 1. Thus, 

128 is a link driver for the 403 UART physical link 130. ZPGM's path is constructed as follows, not unlike the 

Next, the remote node device name stack service queries remote message path of FIG. 2. First, the message stack list 

its message stack drivers for their information. That is, the is constructed as "/ZPDTNF/Link84 12" . Then, the message 

message stack includes those drivers on the message trans- path is reversed, resulting in "/Link8412/ZPDTNF". 

port side of ZPGM 144 (remote node graphics server driver) ^ Thereafter, ZPGM appends itself to the string resulting in 

as opposed to the target device drivers on the target device "/Link8412 ZPDTNF/ZPGM". 

side of ZPGM 144. Put another way, the message stack Then the bridge node ZPGM 236 passes the request for 

includes, in the case of the 1394 communication path, path information on to the node 2 GMZP client 238 which 

ZPDTNF 142 (a 1394 transport driver), and Link8413 140 in turn constructs its local path as "/GMZP/ZPDTerm/ 

(the remote node 136 1394 link driver for the MD8413 45 Terml6550". Bridge node 228 then adds the client string to 

physical link 138). Thus, the following remote device name its bridge string to form "/Link8412/ZPDTNF/ZPGM/ 

message string is built: "/ZPDTNF/Link8413". Then, as in GMZP/ZPDTerm/Terml6550". 

block 28 of FIG. 1, this message string is reversed to form: Thereafter, the bridge node 228 GMZP device stack 

"/Link8413/ZPDTNF". message service sends the request on to the remote node 248 

Next, the target device drivers are compiled in order. 50 device stack message service at ZPGM 256. The node 3 

Therefore, ZPGM 144 adds itself to the target list as: device stack message service then constructs the message 

"ZPGM". Then, the LCD65550 display device 148 driver stack path as 7ZPDTerm/Term403" and then reverses it and 

GM65550 146 adds itself to the list in turn forming: appends ZPGM to it resulting in "/Term403/ZPDTerm/ 

"ZPGM/GM65550". This target device driver string is then ZPGM". The ZPGM device stack message service then 

appended to the remote node message driver string to form: 55 acquires the upstream or target device path as "GM6550" 

"/Link8413/ZPDTNF/ZPGM/GM65550". Thus forming the and appends that to the previously constructed string. The 

remote node device driver communication path in toto. node 3 path thus becomes "/Term403/ZPDTerm/ZPGM/ 

Then, to complete the process for the 1394 communication GM65550", 

path, the remote node message driver string is sent to the The node 3 device name stack service then sends the node 

local node device name stack service to be appended to the 60 3 path string back to the node 2 device name message 

local driver string to form: "/GMZP/ZPDTNF/Link8412/ service which appends the node 3 string to the node 2 path 

Link8413/ZPDTNF/ZPGM/GM65550". This then provides string resulting in '"'/Link8412/ZPDTNF/ZPGM/GMZP/ 

a complete list of drivers, in order, for this 1394 communi- ZPDTerm/Terml6550/Term403/ZPDTerm /ZPGM/ 

cation path. GM65550". The node 2 device name service then sends the 

Likewise, for the RS-232 path, the remote message driver 65 combined path string to node 1. The node 1 device name 

path will be built as: "/ZPDTerm/Terml6550". When message service then appends the node 3+2 path string to the 

reversed it becomes, of course: "/Terml6550/ZPDTerm". node 1 and node 2 path string combination to obtain: 
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'7GMZP/ZPDTNF/Link8413/Link8412/ZPDTNF/ZPGM/ said local node, and adding said gathered upstream 

GMZP/ZPDTernvTerm 16550/Term4O3/ZPDTerm /ZPGM/ device information to an upstream stack driver list until 

GM6555CT. This communication path string is then reported n0 more drivers remain to be added to said upstream 

back to the application 214 fulfilling the application request. stack driver list* 

While embodiments and applications of this invention 5 & said ' tream stack list to Mid reversed order 

have been shown and described, it would be apparent to messaee stack list* 

those skilled in the art that many more modifications than ' 

mentioned above are possible without departing from the said reversed order message stack list and 

inventive concepts herein. The invention, therefore, is not to appended upstream stack list to local node; and 

be restricted except in the spirit of the appended claims. 10 appending said reversed order message stack list and 

What is claimed is: appended upstream stack list to a local driver list. 

1, In a system having a local node and a target node 2. The method of claim 1, wherein said reversed order 
connected to a plurality of nodes located between said local message stack list and appended upstream stack list 
node and said target node, such that multiple communication appended to said local driver list are presented in human- 
paths exist between the nodes of said plurality, a method of 15 rea dable form to allow a user to choose a communication 
constructing a communication path string, the method com- p atn 

prising: 3 The me thod of claim 1, wherein for distributed drivers, 

an application on a local node requesting communication the device name stack service starts by performing activities 

path data; 2Q with capabilities of regular local drivers to produce a list of 

in response to said request for communication path data, names of drivers down to a lowest driver used for transmit- 

gathering driver information on a local node and adding ting messages to a remote node. 

said local node driver information to a message list; 4, The method of claim 3, wherein the device stack 

recursively gathering driver information for nodes con- service sends a message to a remote node requesting its 

nected between said local node and said target node and 2 $ device name stack service. 

sequentially adding said recursively gathered driver 5. The method of claim 4, wherein the remote device 

information to said message list until no more drivers name stack service calls a device name stack service for its 

remain to be added to said message stack list; messaging stack and reverses the order of the list of driver 

reversing the order of driver information contained in said names such that a lowest layer driver name is first and a 

message stack list; 30 highest layer driver name is last. 

recursively gathering upstream device driver information 

for each node connected between said target node and ♦ * * * * 
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